Network congestion generally refers to overloading the resources of a network, such as routers and switches, with packets that need to be handled. When network congestion occurs, packets are dropped by an overloaded resource and have to be retransmitted. Numerous methods and proposals for avoiding network congestion are known, but each has its own drawbacks with respect to issues such as fairness, (e.g., which packets get dropped), enforcement, practical implementation difficulties, and so forth.
For example, in the Transmission Control Protocol (TCP), network congestion is controlled via various phases and techniques, including a congestion avoidance phase. TCP controls its transmit rate by a congestion window that determines the maximum amount of data that may be in transit at any time, wherein a congestion window's worth of data is transmitted every round-trip time. In the absence of congestion, TCP increases its congestion window by one packet each round-trip time. To avoid congestion, if the network drops any packet, TCP halves its congestion window. However, detecting congestion through packet loss, typically as a result of overflow in a router's output queue, has a number of drawbacks including that this method is reactive rather than proactive, as by the time the (often substantial) router buffers are filled up and packets start to get dropped, the network is seriously overloaded. Consequently, the “normal” operating state of the network is to have substantial queuing delays in each router. Moreover, only those flows whose packets are dropped are aware of the congestion, which is why TCP needs to back off aggressively and halve the congestion window. The dropped packets often are not from the source that initially caused the congestion.
A more proactive attempt to avoid network congestion based on the above reduce-on-dropped-packets scheme is “Random Early Detection” (RED). RED operates by randomly discarding more and more packets as the network gets more and more congested, whereby the various sources' TCP congestion avoidance mechanisms halve their congestion windows before full congestion occurs. Packets are discarded with a probability computed from many parameters and variables, including the smoothed length of the forwarding queue. This scheme also has its drawbacks, as among other things, packets are unnecessarily dropped before the network is actually full.
A proposed improvement to TCP/IP, known as Explicit Congestion Notification (ECN), would mark the packets (e.g., that would be dropped in RED) instead of actually dropping them. The mark is returned to the source, whereby the source may slow down its rate of transmission. More particularly, ECN would work to signal the onset of congestion by setting a single bit in the IP packet header. To aid incremental deployment in the Internet, ECN aware traffic flows would identify themselves by setting a further bit in the IP header, whereby non-aware flows could have their packets discarded as normal. When received, the destination (TCP sink) sends back these ECN bits to the source (e.g., in an acknowledgement packet, or ACK) as a TCP option, whereby the source reacts to the ECN signals in the same way as TCP reacts to lost packets, for instance, by halving the congestion window on receipt of such a signal.
To implement an ECN scheme, significant complexity is added at the TCP level to ensure that at least one congestion mark on a packet in a round-trip time's worth of packets has the same effect as a packet loss on the congestion window. To this end, and also to handle the case of delayed ACKs, still further complexity is added to allow the source to signal to the destination, using a Congestion Window Reduced flag, when the source had reduced the rate of its transmission to account for the signal received from the destination. Under this scheme, if policing of users is required, routers may need to run additional code to ensure that flows back off correctly. As can be appreciated, ECN thus has a number of drawbacks, including that complexity is added throughout the network, it only works with modified TCP code, and is particularly difficult to enforce, e.g., an uncooperative source can simply ignore the notification to get more than its fair share of network resources.
Many researchers and implementers have gone to great lengths to ensure that TCP shares out bandwidth fairly among a number of flows sharing a bottleneck. This requires that flows have the same response to congestion events and the same aggressiveness when increasing their bandwidth. In any real network, however, this is not assured, since any unresponsive traffic flows, such as UDP or IP-multicast, will capture the bandwidth they wish from the responsive flows. Also, any user (or web browser) that opens multiple TCP connections will gain a greater share of the bandwidth. Moreover, the network is unable to tell the difference, for example, between a web browser using two TCP connections to fetch the same page, a user using two browsers to fetch two distinct pages, and two users on the same machine (e.g., a terminal server) each fetching a single page with a single browser.
An inherent problem is that traffic sources currently have little incentive to reduce their offered load when faced with congestion, since there is no generic means to detect those sources that do not comply and/or to associate the complying TCP sources with users. There are currently no practical mechanisms for enforcing TCP-compliant behavior.
As an alternative to the above models, theorists have suggested congestion pricing as a possible solution to network congestion problems. In essence, these congestion pricing theories suggest that each router in the network should charge all sources responsible for network congestion, (e.g., by an in-band marking of their packets). Then, in the acknowledgement from the destination or by some other means, each source is notified of the total congestion caused, such that sources will voluntarily reduce their transmit rates based on their “willingness to pay”. However, while such schemes can be shown to have many desirable mathematical properties, they suffer from practical problems, including that the packets initially responsible for creating the load that contributes to subsequent congestion of the network may be forwarded without being marked. Moreover, these models assume that charges can be added to a packet as each resource in the network gets used, which may not be feasible when the congested resource is not easily programmable, such as an existing router that cannot realistically be accessed, or is not programmable at all.